一開始接觸雲端時，我把注意力放在「怎麼把服務跑起來」。
VM 建好了、可以連線，Bucket 也建立完成，看到畫面正常運作，就會覺得事情差不多完成了。
但真正讓我開始踩雷的，反而是最後的清理。
我原本直覺認為：
VM 刪掉了，應該就全部結束了吧？

結果往下一看，才發現 VM 背後還可能有磁碟、IP、服務帳戶等資源。真正麻煩的不是「建立」，而是確定自己真的清乾淨了。

1. 我差點把「刪除 VM」當成「刪除所有東西」

建立 VM 時，我按下的其實只是一個按鈕，但背後同時產生了運算資源、Boot Disk、網路、External IP、Service Account 等不同資源。實際操作時，最容易忽略的就是磁碟與 IP。
這讓我第一次真正意識到：
雲端服務不一定是一個資源，而可能是一組彼此相關的資源。
Google Cloud 官方也明確指出，即使 VM 已經刪除，只要保留 Disk，磁碟仍會持續產生成本。
所以我後來不再只問：
VM 刪掉了嗎？

而是改問：
這個 VM 當初建立了什麼？現在還有哪些需要留下？
這個問題的差異很大。

2. Stop 和 Delete，原來是兩個完全不同的決定

如果只是今天不用 VM，但明天還要繼續工作，Stop 比較合理。
但如果只是一次性的測試環境，繼續保留 VM、Disk、IP，就沒有太大意義。
Google Cloud 也提供 Disk 的 autoDelete 設定，可以決定刪除 VM 時是否同步刪除磁碟。如果選擇保留，之後就必須自己記得清理，而且磁碟即使沒有掛載到 VM，仍可能產生成本。
所以我現在會先判斷：

這是「暫停使用」，還是「生命週期結束」？

前者是 Stop，後者才是 Delete。

3. 我開始用「零殘留清單」取代記憶

光靠記憶其實很容易漏東漏西。
因此我把最後的檢查拆成五項：

• VM 是否已刪除
• Boot Disk 是否還殘留
• External IP 是否釋放
• 測試 Bucket 是否刪除
• 臨時 IAM 權限是否收回

實際驗收時，要求自己每一項都回到管理介面確認，而不是單純相信「我剛剛應該有刪掉」。

4. 下一個問題：不用 VM 的時候，難道每天自己關？

如果每天都要使用 VM，我很可能會遇到另一個問題：
今天下班有沒有記得關？

這其實不是技術問題，而是人很容易忘記事情。
Google Cloud 提供 Instance Schedule，可以依照時間自動啟動與停止 VM。官方也將它定位為協助管理 VM 與最佳化成本的方式。

這讓我開始理解一個很重要的概念：
能自動化的事情，就不要完全依賴人的記憶。

不過排程也不是設定完就什麼都不用管。官方提醒，排程啟停可能比設定時間晚最多 15 分鐘，因此如果真的有時間要求，必須把這個延遲納入設計。

5. 資料也會「變老」

VM 的生命週期解決了，Cloud Storage 又出現另一個問題。
假設我今天把資料放進 Bucket，當下很常使用；三個月後可能幾乎不再碰。
如果資料一直留在原本的 Storage Class，我就必須持續負擔儲存成本。

Cloud Storage 的 Lifecycle Management 可以依照物件條件，自動執行 Storage Class 轉換或刪除。實際操作時，我也注意到生命週期規則修改後，最多可能需要 24 小時才完全生效。

這讓我開始把資料分成：
剛產生、經常使用、很少使用、長期保存
而不是把所有資料都當成同一種資料。

6. Storage Class 不能只看「哪個比較便宜」

我原本很容易把 Storage Class 理解成：
越冷 → 越便宜 → 越划算。

查完官方文件後才發現沒有這麼簡單。
目前 Nearline、Coldline、Archive 分別有 30、90、365 天的最低儲存期間，而且較冷的類別也會有資料取回費用。

所以真正應該問的不是：
哪個最便宜？

而是：
這批資料未來多久會被讀一次？
如果資料每個月都會使用，Nearline 可能合理；如果幾乎一年才會碰一次，Archive 才比較符合它的使用模式。
換句話說，Storage Class 其實是在替「資料未來的使用方式」做決策。

7. 自動化不代表「設定完就不用管」

Lifecycle Rule 很方便，但我也發現一個容易忽略的地方：
規則本身也可能帶來成本或非預期結果。
例如不同 Storage Class 有最低儲存期間，如果太早刪除或重新處理物件，可能產生 early deletion charges。
因此我不會再用：
「30 天後全部搬走」

這種直覺式的規則。
而會先問：

• 這批資料真的 30 天後就不常用嗎？
• 轉換後多久可能被讀取？
• 會不會很快又被搬回來？
• 如果誤刪，是否還有其他保護機制？
  自動化的價值不是少做幾個 Click，而是把正確的判斷變成規則。

8. Budget Alert 也不是「超支就自動關機」

另一個我原本容易誤會的地方是 Budget。
設定 Budget 後，我直覺會認為：
到達預算 → Google Cloud 幫我停止服務。

但官方文件說得很清楚：一般的 alerts-only budget 主要是通知，不會自動限制 Google Cloud 的使用量或支出。
所以 Budget 比較像是：
「你的成本開始接近警戒線了。」

而不是：
「我已經幫你關機了。」
這個差異非常重要。

9. 收到警報後，真正該做的是找原因

假設收到 Budget Alert，知道「花太多錢」其實還不夠。
下一個問題應該是：
到底是哪個 Project、Service 或資源造成的？

Google Cloud 也提供透過 Pub/Sub 發送預算通知的方式，可以進一步串接其他系統，甚至自動化成本控制。

因此成本管理可以從單純：
收到 Email

進一步變成：
發現異常 → 找原因 → 採取行動 → 自動化處理
這比單純設定一個預算數字更有意義。

結語

雲端最容易讓人忽略的，可能不是「怎麼建立」，而是「什麼時候應該結束」。
最後開始養成一個習慣：
每建立一個雲端資源，就同時思考它最後怎麼離場。